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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the procedures and the transport protocol for use in the Muhimedia Messaging Service 
(MMS) based on Diameter. 

The present document is appUcable to: 

- The MMIO interface between an MMS Relay/Server and the MSCF. 

Whenever it is possible this document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of Diameter. Where this is not possible, extensions to Diameter are defined 
within this document. 



References 



The following documents contain provisions, which through reference in this text constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 23.140: "Multimedia Messaging Service (MMS); Functional description; Stage 2". 
[2] 3GPP TS 33.210: "3G Security; Network Domain Security; IP Network Layer Security". 

[3] IETF RFC 2960: "Stream Control Transmission Protocol". 

[4] IETF RFC 3588: "Diameter Base Protocol". 

[5] IETF RFC 2234: "Augmented BNF for syntax specifications". 

[6] Open Mobile Alliance; OMA-MMS-ENC-vl_2-20030915-C; Multimedia Messaging Service; 

Encapsulation Protocol, Version 1 .2 

[7] 3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol; Protocol details" 

[8] 3GPP TS 23.003: "Numbering, addressing and identification" 

[9] IETF RFC 2960: "Stream Control Transmission Protocol". 

[10] IETF RFC 3309: "Stream Control Transmission Protocol (SCTP) Checksum Change". 

[II] 3GPP TS 29.329: "Sh Interface based on the Diameter protocol; Protocol details". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

Refer to IETF RFC 3588 [4] for the definitions of some terms used in this document. 
For the purposes of the present document, the following terms and definitions apply. 
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Messaging Service Control Function: Network element hosting network operator specific services enhancing the 
capabilities of the MMS. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAA Authentication, Authorization and Accounting 

AS Application Server 

ABNF Augmented Backus-Naur Form 

AVP Attribute-Value Pair 

lANA Internet Assigned Numbers Authority 

IETF Internet Engineering Task Force 

MSCF Messaging Service Control Function 

NDS Network Domain Security 

RFC Request For Comment 

SCTP Stream Control Transport Protocol 

UCS Universal Character Set 

URL Uniform Resource Locator 

UTF UCS Transformation Formats 



Procedure Description 



In the tables that describe the information elements transported by each command, each Information Element is marked 
as (M) Mandatory, (C) Conditional or (O) Optional. A mandatory information element shall always be present. A 
conditional information shall be present if certain conditions are fulfilled; if those conditions are not fulfilled it shall be 
absent. An optional information element may be present or absent in the command, at the discretion of the application at 
the sending entity. 

The classification of information elements on application level is provided in 3GPP TS 23.140 [1]. The present 
document provides the classification on protocol level, which may differ from the application requirements. 



4.1. IVIMIO Interrogation Procedure 



This procedure is used between the MMS Relay/Server and the MSCF. This procedure is invoked by the MMS 
Relay/Server and is used to request processing of addressing information related to a multimedia message (see 3GPP TS 
23.140 [1]). 

This procedure is mapped to the commands Message-Process-Request/Answer in the Diameter application specified in 
section 6. L Tables 4. L L 1 and AAA. 2 detail the involved information elements. 
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4.1.1 



Information Elements 



Table 4.1.1.1: MM10 Interrogation Request 



Information 
element name 


IVIapping to 
Diameter AVP 


Cat. 


Description 


Message Type 


Diameter 

Command 

Code 


M 


Identification of the MM10 message. 


Trigger Event 


Trigger-Event 


M 


Identification of the event leading to invocation of the MM1 interrogation 


Served User 
Identity 


Served-User- 
Identity 


M 


This information element contains the identification of the served user. 


Served User 
IMSI 


Served-User- 
IMSI 


C 


This information element contains the identity of the mobile subscriber 
(ll\/ISI). This element shall be present if received via the access. 


Initial 
Recipient 
Address 


Initial- 

Recipient- 

Address 


M 


This information element contains the recipients of a multimedia message 
as requested by the sender. In case of multiple recipients multiple 
occurrences of this information element shall apply. 


Originating 
Interface 


Origination 
Interface 


M 


This information element identifies the interface the multimedia message 
has been received on. 


Service Key 


Service-Key 


C 


This information element contains identification of the application on the 
MSCF. It shall be present if the IVIMS Relay/Server trigger configuration 
contains this information. 


Sender 
Address 


Sender- 
Address 


C 


This information element contains the identity of the sender to be presented 
to the recipient. This information element shall be available if contained in 
the multimedia message. 


Delivery 
Report 


Delivery- 
Report 


c 


This information contains information about the users request for delivery 
reports. This information element shall be present if the request has been 
received in the multimedia message. 


Read Reply 


Read-Reply 


c 


This information contains information about the users request for read reply 
reports. This information element shall be present if the request has been 
received in the multimedia message. 


Sender 
Visibility 


Sender- 
Visibility 


c 


This information element contains information about the users request to 
hide the own identity. This information element shall be present if the 
request has been received in the multimedia message. 



Table 4.1.1.2: MM10 Interrogation Response 



Information 
element name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Message Type 


Diameter 

Command 

Code 


M 


Identification of the MM10 message. 


Result Code 


Result-Code 


M 


This information element contains the result of the operation. 


Status 





This information element contains message status information to notify the 
served user about the outcome of the message processing. 


Status-Text 





This information element contains a response status text to qualify the 
outcome of the message processing. 


Result 
Address 


Result- 

Recipient- 

Address 


C 


This information element contains the recipient address information 
resulting from the MSCF processing. This information element shall be 
available if a success result code is contained. 


Delivery 
Report 


Delivery- 
Report 





This information element contains the delivery report request information 
resulting from the MSCF processing. 


Sender 
Visibility 


Sender- 
Visibility 





This information element contains the sender visibility request information 
resulting from the MSCF processing. 


Read Reply 


Read-Reply 





This information element contains the read reply request information 
resulting from the MSCF processing. 


CDR 
Information 


Billing- 
Information 





This information element contains transparent billing data resulting from the 
MSCF processing. 
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4.1.2 Normal Operation 



If the MMS Relay/Server sends MM 10 interrogation request to the MSCF after it has detected that a multimedia 
message is subject to processing in the MSCF. The MMIO interrogation request contains the message data as received 
from the served user. 

A MMIO interrogation response received from the MSCF may be composed as follows: 

■ If the MMIO interrogation response contains a D1AMETER_SUCCESS result code, then the MSCF has 
authorised the message request unconditionally. The MMS Relay/Server shall continue to process the 
multimedia message unmodified 

■ If the MMIO interrogation response contains a DIAMETER_L1M1TED_SUCCESS result code, then the 
MSCF has requested some modifications to the message. The MMS Relay/Server shall continue message 
processing with the updated data received form the MSCF. 

■ If the MMIO interrogation contains a DIAMETER. AUTHORIZATION_REJECTED result code, then the 
message attempt is not authorised. The MMS Relay/Server shall reject the message request. If a status 
information is received from the MSCF, this shall be used to notify the sender about the outcome. 



Use of the Diameter base protocol 



The Diameter Base Protocol as specified in IETF RFC 3588 [4] shall apply except as modified by the defined support 
of the methods and the defined support of the commands and AVPs, result and event codes specified in clause 6 of this 
specification. Unless otherwise specified, the procedures (including error handling and unrecognised information 
handling) are unmodified. 

5.1 Securing Diameter IVIessages 

For secure transport of Diameter messages, see 3GPP TS 33.210 [2]. 



5.2 Accounting functionality 



Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the 
MMIO interface. 

5.3 Use of sessions 

Diameter sessions are implicitly terminated between the MMS Relay/Server and the MSCF. An implicitly terminated 
session is one for which the server does not maintain state information. The client does not need to send any re- 
authorization or session termination requests to the server. 

The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of 
implicitly terminated sessions. 

The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value 
NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [4]. As a consequence, the server does not maintain 
any state information about this session and the client does not need to send any session termination request. Neither the 
Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 



5.4 Transport protocol 



Diameter messages over the MMIO interface shall make use of SCTP IETF RFC 2960 [9] and shall utilise the new 
SCTP checksum method specified in RFC 3309 [10]. 
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5.5 Routing considerations 

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. 

The MMS Relay/Server shall derive the address/name of the MSCF for a certain user or use case from the MMS user 
profile or from the MMS Relay/Server configuration. The MMS Relay/Server shall present both the Destination-Realm 
and Destination-Host AVPs in the request. Consequently, the Destination-Host AVP is declared as mandatory in the 
ABNF for all requests initiated by the MMS Relay/Server. 

Requests initiated by the MSCF towards MMS Relay/Server shall include both Destination-Host and Destination-Realm 
AVPs. The MSCF obtains the Destination-Host AVP to use in requests towards an MMS Relay/Server, from the 
Origin-Host AVP received in previous requests from the MMS Relay/Server. Consequently, the Destination-Host AVP 
is declared as mandatory in the ABNF for all requests initiated by the MSCF. 

5.6 Advertising Application Support 

The MMS Relay/Server and MSCF shall advertise support of the Diameter MM 10 interface Application by including 
the value of the application identifier (see chapter 6) in the Auth- Application-Id AVP within the Vendor-Specific- 
Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. 

The vendor identifier value of 3GPP (10415) shall be included 

• in the Supported- Vendor-Id AVP and 

• in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP 
of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. 



6 Diameter application for MM1 interface 

This clause specifies a Diameter application that allows a Diameter client and a Diameter server: 

to indicate that a submission or delivery request for a multimedia message has been received. The Diameter 
client provides the message data and additional data qualifying the messaging event to the server. 

to request in result to continue the processing of the multimedia message with the original or modified 
information or to reject the multimedia message. 

The MMIO interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. 
The vendor identifier assigned by lANA to 3GPP ( http://www.iana. org/assignments/enterprise-numbers ) is 10415. 

The Diameter application identifier assigned to the MMIO interface application is TBD (allocated by lANA). 

6.1 Command-Code values 

This section defines Command-Code values for this Diameter application. 

Every command is defined by means of the ABNF syntax (as defined in RFC 2234 [5]), according to the rules in IETF 
RFC 3588 [4]. Whenever the definition and use of an AVP is not specified in this document, what is stated in IETF 
RFC 3588 [4] shall apply. 

NOTE: AVP defined in this specification are highlighted bold in the ABNF syntax. 

The command codes for the MMIO interface application are taken from the range allocated by IAN A as assigned in this 
specification. For these commands, the Application-ID field shall be set to TBD (application identifier of the MMIO 
interface application, allocated by lANA). 

NOTE: Registration in lANA to be done; once assigned, value will need to be added. 

The following Command Codes are defined in this specification: 
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Table 6.1.1 : Command-Code values 



Command-Name 


Abbreviation 


Code 


Section 


Message-Process-Request 


MPR 


tbd 


6.1.1 


Message-Process-Answer 


MPA 


tbd 


6.1.2 



6.1 .1 Message-Process-Request (MPR) Command 

The Message-Process-Request (MPR) command, indicated by the Command-Code field set to TBD and the 'R' bit set 
in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request the processing of a 
multimedia message. 

Message Format 



<Message-Process-Request> ::= < Diameter Header: tbd, TBD, REQ, PXY > 

< Session-Id > 

{ Vendor-Specific-Application-Id } 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
{ Destination-Host } 
{ Destination-Realm } 
{ Event-Timestamp } 
{ Trigger-Event } 
{ Served-User-Identity } 
[ Served-User-IMSI ] 
[ Sender- Address ] 
*[ Initial-Recipient- Address ] 
{ Originating-Interface } 
[Service-Key] 
[ Delivery-Report ] 
[ Read-Reply ] 
[ Sender- Visibility ] 
*[ AVP ] 
*[ Proxy-Info ] 
*[ Route-Record ] 

6.1 .2 Message-Process-Answer (MPA) Command 

The Message-Process-Answer (MPA) command, indicated by the Command-Code field set to TBD and the 'R' bit 
cleared in the Command Flags field, is sent by the Diameter server in response to the Message-Process-Request 
command. The Result-Code or Experimental-Result AVP may contain one of the values defined in section 6.2 in 
addition to the values defined in RFC 3588 [4]. 



Message Format 



< User-Data- Answer > ::= 



< Diameter Header: tbd: TBD > 
< Session-Id > 

{ Vendor-Specific-Application-Id 
[ Result-Code ] 
[ Experimental-Result ] 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
[ Status ] 

*[ Result-Recipient- Address ] 
[ Delivery-Report ] 
[ Read-Reply ] 
[ Billing-Information 
*[ AVP ] 
*[ Proxy-Info ] 
*[ Route-Record ] 
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6.2 



Result-Code AVP values 



This section defines new result code values that must be supported by all Diameter implementations that conform to this 
specification. When one of the result codes defined here is included in a response, it shall be inside an Experimental- 
Result AVP and Result-Code AVP shall be absent. 

6.2.1 Success 

Errors that fall within the Success category are used to inform a peer that a request has been successfully completed. 
No errors within this category have been defined in this release. 

6.2.2 Permanent Failures 

Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not 
be attempted again. 

No errors within this category have been defined in this release. 

6.2.3 Transient Failures 

Errors that fall within the transient failures category are those used to inform a peer that the request could not be 
satisfied at the time that it was received. The request may be able to be satisfied in the future. 

No errors within this category have been defined in this release. 



6.3 



AVPs 



The following table describes the Diameter AVPs defined for the MMIO interface protocol, their AVP Code values, 
types, possible flag values and whether the AVP may or not be encrypted. 

Table 6.3.1 : Diameter MMIO Application AVPs 











AVP Flag rules 




Attribute Name 


AVP 
Code 


Section 
defined 


Value Type 


Must 


May 


Should 
not 


Must 
not 


May Encr. 


Served-User-ldentity 


TBD 


6.3.1 


Grouped 


M 


V 








N 


MSISDN 


101 


6.3.2 


OctetString 


M 


V 








N 


VASP-ID 


TBD 


6.3.3 


UTF8String 


M 


V 








N 


VAS-ID 


TBD 


6.3.4 


UTF8String 


M 


V 








N 


Trigger-Event 


TBD 


6.3.5 


Enumerated 


M 


V 








N 


Served-User-IMSl 


TBD 


6.3.6 


OctetString 


M 


V 








N 


Sender-Address 


TBD 


6.3.7 


UTF8String 


M 


V 








N 


Initial-Recipient-Address 


TBD 


6.3.8 


Grouped 


M 


V 








N 


Result-Recipient-Address 


TBD 


6.3.9 


Grouped 


M 


V 








N 


Sequence-Number 


TBD 


6.3.10 


Unsigned32 


M 


V 








N 


Recipient-Address 


TBD 


6.3.11 


UTF8String 


M 


V 








N 


Routeing-Address 


TBD 


6.3.12 


UTFSString 


M 


V 








N 


Originating-lnterface 


TBD 


6.3.13 


Enumerated 


M 


V 








N 


Delivery-Report 


TBD 


6.3.14 


Enumerated 


M 


V 








N 


Read-Reply 


TBD 


6.3.15 


Enumerated 


M 


V 








N 


Sender-Visibility 


TBD 


6.3.16 


Enumerated 


M 


V 








N 


Service-Key 


TBD 


6.3.17 


UTF8String 


M 


V 








N 


Billing-Information 


TBD 


6.3.18 


UTF8String 


M 


V 








N 


Status 


TBD 


6.3.19 


Grouped 


M 


V 








N 


Status-Code 


TBD 


6.3.20 


UTF8String 


M 


V 








N 


Status-Text 


TBD 


6.3.21 


UTF8String 


M 


V 








N 


NOTE 1 : The AVP header bit denoted as 'IVI', indicates whether support of the AVP is required. The AVP header 
bit denoted as 'V, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, 
see IETF RFC 3588. 
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6.3.1 Served-User-ldentity AVP 



The User-Identity AVP (AVP Code TBD) is of type Grouped. This AVP contains identity of the served subscriber for 
whom a messaging processing is requested. 

AVP format 

User-Identity ::= <AVP header: TBD 10415> 

[MSISDN] 

[VASP-Code] 

[VAS-Code] 

*[AVP] 

6.3.2 MSISDN AVP 

The MSISDN AVP contains MSISDN. For is the definition of this AVP refer to 3GPP TS 29.329 [II]. 

6.3.3 VASP-IDAVP 

The VASP-ID AVP (AVP Code TBD) is of type UTFSString. This AVP contains the identification of a Value Added 
Service Provider. 

6.3.4 VAS-IDAVP 

The VAS-ID AVP (AVP Code TBD) is of type UTFSString. This AVP contains the identification of a Value Added 
Service. 



6.3.5 Trigger-Event AVP 



The Trigger-Event AVP (AVP code TBD) is of type Enumerated. It indicates the type of the event that triggered the 
Message-Process-Request. 

MM I Message Submission, Profile based (0) 

MMI Message Submission, Address based (1) 

MMl Message Delivery (2) 

MM7 Message Submission, Profile based (3) 

MM7 Message Submission, Address based (4) 

6.3.6 Served-User-IMSI 

The Served-User-IMSI AVP (AVP Code TBD) is of type OctetString. This AVP contains an IMSI as described in 
3GPPTS 23.003 [8] encoded as a TBCD-string, i.e. digits from through 9 are encoded 0000 to 1001; 1111 is used as a 
filler when there is an odd number of digits; bits 8 to 5 of octet n encode digit 2n; bits 4 to 1 of octet n encode digit 2(n- 
I)+I. 

6.3.7 Sender-Address AVP 

The Sender- Address AVP (AVP code TBD) is of type UTFSString. This AVP contains the identification of a 
multimedia message sender to be provided to the multimedia message recipient. 



£75/ 



3GPP TS 29.1 40 version 6.0.0 Release 6 1 4 ETSI TS 1 29 1 40 V6.0.0 (2004-1 2) 



6.3.8 Initial-Recipient-Address AVP 



The Initial-Recipient- Address AVP (AVP code TBD) is of type Grouped. It contains recipient address information sent 
to the MSCF. 

Result-Recipient-Address ::= <AVP header: TBD 10415> 

[Sequence-Number] 

[Recipient- Address] 

*[AVP] 



6.3.9 Result-Recipient-Address AVP 



The Result-Recipient- Address AVP (AVP code TBD) is of type Grouped. It contains recipient address information as 
returned from the MSCF. 

Result-Recipient-Address ::= <AVP header: TBD 10415> 

[Sequence-Number] 

[Recipient- Address] 

[Routeing-Address] 

[Sender- Address] 

[Sender- Visibility] 

*[AVP] 

6.3.10 Sequence-Number AVP 

The Sequence-Number AVP (AVP code TBD) is of type Unsigned32. It contains the unique identification (counter) of 
a recipient address group. 



6.3.11 Recipient-Address AVP 



The Recipient- Address AVP (AVP code TBD) is of type UTFSString. It contains the Recipient address of a multimedia 
message. The UTFSString identifying the Recipient shall be represented according to the following ABNF definition: 

Recipient- Address = {recipient type} {recipient} 

Recipient Type = ( "To:" / "Cc:" / "Bcc:" ) 

Recipient = address ; address is coded according to the MMS addressing model defined in [6]. 



6.3.12 Routeing-Address AVP 



The Routeing-Address AVP (AVP code TBD) is of type UTFSString. It contains the Recipient address for routeing of a 
multimedia message. The UTFSString identifying the Recipient shall be represented according to the following ABNF 
definition: 

Routeing-Address = [Recipient-Type] [Recipient] 

Recipient-Type = ( "To:" / "Cc:" / "Bcc:" ) 

Recipient = ( Address / MM4- Address ) 

Address; it is coded according to the MMS addressing model defined in [6]. 

MM4-Address; it is coded according to the MM4 address encoding model on SMTP protocol level defined in [1] 
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6.3.13 Originating-lnterface AVP 

The Originating-Interface-AVP (AVP code TBD) is of type Enumerated. It indicates the interface a multimedia 
Message has been received on. 

MMl (0) 

MM3 (1) 

MM4 (2) 
MM7 (3) 

6.3.14 Delivery-Report AVP 

The Delivery-Report AVP (AVP code TBD) is of type Enumerated. It indicates whether an delivery report is requested. 

No Delivery Report Requested (0) 

Delivery Report Requested (1) 
If the Delivery-Report AVP is not present, then the default "No Delivery Report Requested" shall be assumed. 

6.3.15 Read-Reply AVP 

The Read-Reply AVP (AVP code TBD) is of type Enumerated. It indicates whether a delivery report is requested. 

No Read Reply Requested (0) 

Read Reply Requested (1) 
If the Read-Reply AVP is not present, then the default "No Read Reply Requested" shall be assumed. 

6.3.16 Sender-Visibility AVP 

The Sender- Visibility AVP (AVP code TBD) is of type Enumerated. It indicates whether the sender identification is 
requested to be hidden or not. 

Sender Identification requested not to be hidden (0) 

Sender Identification requested to be hidden (1) 

If the Sender- Visibility AVP is not present, then the default "Sender Identification requested not to be hidden" shall be 

assumed. 

6.3.17 Service-Key AVP 

The Service-Key AVP (AVP code TBD) is of type UTFSString. It identifies an application of the target MSCF. 

6.3.18 Billing-Information AVP 

The Billing-Information AVP (AVP code TBD) is of type UTFSString. It contains transparent information to be 
forwarded to the billing system. 

6.3.19 Status AVP 

The Status AVP (AVP code TBD) is of type Grouped. It contains message status information to allow notification of 
the served user. 

Result-Recipient-Address ::= <AVP header: TBD 10415> 

[Status-Code] 
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[Status-Text] 

6.3.20 Status-Code AVP 

The Status-Code AVP (AVP code TBD) is of type UTFSString. It contains the trigger event specific response code to 
qualify the outcome of the message processing. The UTFSString identifying the Status-Code shall be represented 
according to the following ABNF definition: 

Status-Code = ( Response-status-value / Retrieve-status-value / StatusCode ) 

Response-status-value; it contains the numerical octet value of the M-send.conf X-Mms-Response-Status header 
defined in [6]. This Status-Code value shall be used by the MSCF if the Trigger-Event of the Message-Process- 
Request referred to MMl Message Submission. 

Retrieve-status-value; it contains the numerical octet value of the M-Retrieve.conf X-Mms-Retrieve-Status 
header defined in [6]. This Status-Code value shall be used by the MSCF if the Trigger-Event of the Message- 
Process-Request referred to MMl Message Delivery. 

StatusCode; it contains the numerical value of the MM7_submit.RES StatusCode element defined in [1]. This 
Status-Code value shall be used by the MSCF if the Trigger-Event of the Message-Process-Request referred to 
MM7 Message Submission. 

6.3.21 Status-Text AVP 

The Status-Text AVP (AVP code TBD) is of type UTFSString. If contains a response status text to qualify the outcome 
of the message processing. 



6.4 Use of namespaces 



This clause contains the namespaces that have either been created in this specification, or the values assigned to existing 
namespaces managed by IAN A. 

6.4.1 AVP codes 

This specification assigns the values TBD-TBD from the AVP Code namespace managed by 3GPP for its Diameter 
vendor-specific applications. See section 6.3 for the assignment of the namespace in this specification. 

6.4.2 Experimental-Result-Code AVP values 

This specification assigns no Experimental-Result-Code AVP values in this release. 

6.4.3 Command Code values 

This specification assigns the values tbd and tbd from the range allocated by lANA to 3GPP. 

6.4.4 Application-ID value 

lANA has allocated the value TBD for the 3GPP MM 10 interface application. 



Special Requirements 



7.1 Version Control 

The same mechanisms specified in 3GPP TS 29.229 [6] apply to this specification. 
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